A Technical Overview of the Mobile Web : THE MOBILE NETWORK

1. Data Networks

As you might imagine, the networks responsible for bringing content and services to a mobile device are also notably different from the networks to which you connect laptops and desktops. Many contemporary mid- and high-end mobile devices include WiFi data connectivity, and when used in that mode, the device is connecting to a local access point, which, in turn, is most likely connected to a regular broadband-grade connection. In this case, the network connection for the device is fast, reliable, and low in latency — just as it is for the other computers and devices that are connected through the same access point and service provider.

But leave the limits of the hotspot, and your mobile device needs to revert to the cellular network for its data connection. At this point, the behavior and characteristics of the connection can change dramatically. A responsible web developer needs to be aware of these likely characteristics — and how the device mitigates them — in order to ensure that the user still retains a pleasant experience.

Throughout the world, a small number of prevalent cellular and mobile data technologies are in regular use. The most widespread, by both geography and number of users, is the Global System for Mobile Communications (GSM) and its evolutions, which provide over 4 billion connections in over 200 countries worldwide, including the United States. A rival family of standards, broadly termed CDMA, is also popular in the United States, China, and a number of other countries. Japanese networks offer particular implementations of various types, including some proprietary network technologies.

In most developed and some developing markets, network technologies have reached a third-generation of data access, sometimes known as 3G, providing speeds up to 2Mbps. These include UMTS (also known as W-CDMA), generally deployed by GSM network carriers, and CDMA2000, deployed by their CDMA brethren. In the United States, AT&T and T-Mobile offer UMTS data networks, while Verizon and Sprint have CDMA2000 networks.

Markets that have not yet reached widespread 3G coverage but still provide data services (notably in the least-developed countries and many developing countries), tend to provide slower 2.5G or 2.75G data technologies. Most common of these are the GSM-based GPRS which provides speeds up to 60Kbps, and EDGE which provides speeds up to 240Kbps.

Looking forward, fourth generation mobile technologies, including Advanced Long Term Evolution (LTE), are, at time of writing, in the process of being specified and standardized, but theoretically offer speeds up to 1Gbps. Sadly, such networks and devices are unlikely to be widespread for several years. In the interim, many networks provide transitional 3.5G technologies, such as HSDPA, EV-DO, and WiMAX, all of which, with speeds of between 3Mbps and 14Mbps, offer significant increases of speed and capacity to the 3G platform.

2. Throughput and Latency

Although these acronyms and the constant evolution of cellular and wireless network technology can be baffling, the important thing to understand is that a variety of networks are used to provide data connections to your users' devices. As with the physical and diversity-related challenges of the devices themselves, you need to be cautious about assumptions for these connections.

Speed or throughput of the network connection is an obvious constraint. At the end of 2010, according to Akamai, the average fixed-line broadband speed in the United States was 5Mbps, many factors faster than even the theoretical peak speed of most mobile networks. This has a direct impact on the users' Web experience because it defines the minimum time that an uncached web page takes to download to a device. You're probably not surprised to read that many mobile devices also do not have comprehensive or long-lived caching capabilities, thanks to their memory constraints.

A user with a 3G UMTS connection in the United States might expect an average download speed of 250Kbps, and 750Kbps on HSDPA (although such speeds are drastically affected by movement and the density of other data users in the local area). Even this is six times slower than a typical wired desktop experience: A web page containing a 1Mb video file might load in 2 or 3 seconds on a desktop, but it would take at least 15 seconds on a fast mobile network. That may be longer than an impatient user on the go is prepared to wait for the download. If you expect to deliver rich media to your mobile web users, you certainly need to look at limiting or adapting file sizes.

In addition to pure speed, other factors significantly affect the impact of the network on the user experience. One is the setup time for the data connection itself. A desktop or laptop computer usually has a persistent connection to the Web, and the first page visited by a user starts to download immediately. Most devices, on the other hand, connect on demand (in order to preserve power when the data connection is not in use), and this can add as much as 5 to 7 seconds to the time for the first page to be requested. Your users may already be impatient by the time your page even starts downloading.

A more persistent but often overlooked consideration is that of roundtrip latency. This is a measure of the time taken for data packets to proceed from the device, through the network, to the destination service, and back again, although excluding the time actually taken for the server to perform any processing. This is influenced entirely by the type and topology of the network, the route the packets take, and any intermediate proxies or gateways that process the data en route.

On a fixed-line ADSL connection, latency is so low that it is barely considered. Regardless of the throughput speed, a ping time of less than 80 milliseconds to most web servers can be assumed from within the United States, and at most a few 100ms to internationally hosted servers.

On a mobile network, however, latency is a real consideration. This is partly because packets sent from a mobile device to a public web server traverse a number of sub-networks and their boundaries. First, there is the cellular air interface to a nearby cell station — which has a particularly significant impact on latency — then a backhaul link to the network carrier's switching center. Then there is a sequence of gateways that connect the traffic, often through firewalls and proxies, to the Internet, and then finally the packet proceeds through web infrastructure to the server. The effects on latency can be significant.

AT&T quotes a latency overhead of between 100ms and 200ms for requests to servers immediately external to their current UMTS and HSDPA networks, and 600ms over their GPRS and EDGE networks. While this is impressive, given the complexity of the cellular network involved, you should still expect the latency of a typical browser-to-server-to-browser roundtrip to be an order of magnitude longer than for a broadband connection.

In some respects, latency is more important than the raw throughput of the network, and this is particularly true for web applications, where a page is made up of a large number of component parts. The request for each graphic, each style sheet, and each external script is delayed by the latency of the network, and if those objects are small, this can easily dominate the total time taken for the page to fully download. Web developers can take real action to mitigate these effects, such as combining CSS files, using sprite techniques for interactive images, and tuning cache settings for external objects.

3. An Introduction to Transcoding

To repeat the theme, mobile browsers are limited in many ways relative to their desktop and laptop brethren. The less capable the browser is of rendering a full web page — and the less powerful the device is to undertake any reformatting of it — the more emphasis you must place on ensuring that the content that reaches the device is light and simple enough to render quickly and pleasingly.

As web designers and developers, you are by far in the best position to judge how your content should be altered to work well on mobile devices. Which aspects of the design are essential? Which parts of the site are best suited for mobile users? Which sidebars are expendable? How small are you prepared to let your logo render on a mobile screen? These and many other questions are surely best answered by humans: the brand, site, or content owners.

But these are still early years for the mobile web, and the vast majority of content that exists on the traditional web remains unsuited for mobile devices. The web addresses that average users know (from their desktop experience of the Web) are undoubtedly the non-mobile variants of the sites. Therefore, if a user starts her mobile browser for the first time and enters an arbitrary URL (in response to which the device receives a large, complex, media-laden site), the experience is likely to be disappointing, and the user may be unlikely to try again.

To avoid this outcome, many network carriers install proxies into their networks that actively adapt such web content on the fly, so the page that the device receives is likely to be smaller, simpler, and without large incompatible graphics. These proxies are popularly known as transcoders and are provided by companies such as Volantis and Bytemobile to be installed within the carrier network. The transcoding process typically affects the markup of your website by removing extraneous tags, reformatting tables and page layout, and paginating long text, including images and media within it.

Transcoding technology also exists outside the carrier network. The Opera Mini and Mobile browsers rely on Opera-run proxy servers to optimize, compress, and cache content on behalf of the device browser. And many search engines, including Google and Microsoft, provide links to transcoded versions of the websites returned for search queries made by mobile devices.

Figures 1 and 2 demonstrate the difference between the original website (Figure 1) and its transcoded appearance on a mobile device (Figure 2-13), in this case, via Microsoft's Bing search results.

Figure 1.

Figure 2.

Because these solutions are using machine logic to make design and layout decisions, the results can be variable and are rarely as elegant and usable as a website that has been designed, by a human, specifically for mobile devices. It is better than nothing that the users can access the site, but it's not recommended as an alternative to treating mobile users as first-class visitors to your site. You can avoid rendering issues such as those shown in these figures by ensuring that your server emits a mobile-friendly site in the first place.

In addition to their often disappointing results, transcoders are controversial for a number of reasons. First, users may not know that the web experience they are receiving is being manipulated in this way (particularly if it is a proxy embedded within the carrier's network). A user's disappointing impression of a website reflects badly on that site owner or brand — not on the carrier whose network infrastructure caused the problem. For this reason, many content owners are keen to opt out of having their content actively transcoded. A worthwhile discussion concerns whether default reformatting of web content by a third party even challenges the site owners' copyright of their own material.

But perhaps the most frustrating issue with transcoding proxies occurs when a diligent web developer has indeed created web content designed specifically for mobile browsers, perhaps selected for the user based on the HTTP headers his device has sent. It would be natural for a transcoder to allow this to pass through transparently, but sadly this does not always happen, and in many networks content gets even further manipulated on its way back to the browser, beyond the developer's obvious intentions and with serious effects for the appearance and functionality of the site. Worse, many transcoders alter the HTTP request made by a device to make it look like it originated from a traditional web browser, further confusing the situation: A user may receive a poorly transcoded facsimile of her desktop site when a beautiful mobile version did exist and could have been presented to her.

Despite the community debate and controversy that transcoders have caused in recent years, a mobile web developer can defend against their behavior in several ways. You can detect changes made to the HTTP request by such proxies and add extra headers to the response to indicate that it should not be further manipulated. Active members of the developer community — and the World Wide Web Consortium itself — have worked with transcoding vendors to ensure a degree of understanding about how to act responsibly in a complex, yet nascent, mobile web ecosystem. 

4. Firewalls and Security

No discussion of any new set of technologies is complete without the important topic of security. In general, all the security issues and considerations applicable to the regular Web are still relevant for the mobile web. But again, you need to take into account a number of additional matters.

You have already seen a number of active entities within the mobile network, such as gateways, proxies, and transcoders. Each of these has the potential to affect your confidence in the security and accessibility of your service.

One simple restriction a web developer often experiences is the ability to access various TCP/IP ports through a mobile network. Port 80 on the web server (which is the standard HTTP port for web access) should be available to a mobile user's device for basic web browsing. However, depending on the network carrier's configuration, that may be the only port available, and other common ports such as 81, 8000, and 8080 may well be off-limits. This can be awkward if one uses alternative ports for development or pre-deployment versions of a website (which still need to be accessed with real devices by a test team), and in such cases, alternative domain names or sub-domains are recommended.

Similar issues may arise with streamed video or other embedded media, which rely on unusual TCP/IP ports to function. The network simply may not let the traffic through to the device, and the functionality will be lost.

Most networks theoretically allow HTTPS connections to web servers on port 443, and many types of mobile websites or services would benefit from secure connections, including e-commerce-based sites, banking, or private enterprise applications. However, web developers must be aware that the presence of proxies and transcoders in the mobile carrier network can potentially compromise any assumed end-to-end security. If a transcoder is to manipulate an HTTPS page on behalf of a low-capability device, it can do so only by establishing the secure connection with the site itself, decrypting the content, performing its conversions (theoretically in the clear), and then re-encrypting it to create a second secure link with the device. It's easy to believe that a mobile carrier network is a secure, trustable environment, but it is certainly not clear that a user will understand that his secure data is being manipulated mid-network and is potentially subject to malicious intent.

For those web connections that can avoid any such transcoding within the network, most browsers are theoretically capable of maintaining their own end-to-end secure connection with a web server.

However, another issue often exists in the form of the certificates used to identify a site: Many low-end or older devices do not have a large set of root certificates installed with their browser. This may mean that even a valid, signed certificate on a reputable website can result in an alarming warning to the user. Figure 3 shows such a warning when a user visits the Amazon mobile website with a Nokia E70 device.

Away from the network itself, a number of other security considerations are particular to the mobile web. In particular, a mobile device itself is often used for storing highly sensitive data, and you should expect that users will store bookmarks and cache passwords related to your services. Unlike with a desktop computer, however, accidentally leaving a mobile browser in the back of a taxi, for example, is a real possibility — and if you are providing sensitive website services, you should provide defensive functionality against lost and stolen browsers. These might include shortening the length of session and cookie lifetimes for account logins, proactively detecting unusual usage of a site, and a desktop-based ability for the user to temporarily disable mobile access to their account.

Figure 3.